A few bugs left... WoW classic has been released, which means several of our top men have taken time off to spend hours raiding and having fun in Azeroth. This isn't great timing, as a few new bugs related to train signals appeared. We want to get these bugs solved before we do another release (another stable candidate). As it turns out, the only person with the skillset to fix these specific train signal bugs is also deep into levelling his Priest... (Kov on Pyrewood Village) We are still making the rest of the preparations for the stable release. We have started writing up the stable annoucement blog post, and have produced a 0.17 postcard image. Other than the few more critical rail bugs, there doesn't look like there is much else to block the stable release, on the forum we are down to 27 bugs. Since there are so few bugs left to deal with, some of the team has starting working on 'post-stable' features. Wheybags is working on the new campaign, Oxyd is diving into some detailed pathfinder improvements, and Rseding has started work on some particle optimizations. We will delve deeper into these topics and more in future FFFs, as we always love to do.

The boring phase of bug-fixing is still going, slowly but surely. Stable should be released next week, but with some people on vacation (Ben, Jitka, kovarex, Klonan, Sanqui) and with the release of WoW Classic, it might get slowed down a bit. (By the way, some of us will be playing on Pyrewood Village, Alliance, so if you want to have the chance of meeting Twinsen, kovarex or dominik while leveling, you can join that server). So since there's not much happening, this week we decided to explore some unpopular or controversial opinions about the game from within the team. In Wube we don't have a very strict management structure, everyone is free to have ideas and opinions about almost all aspects of the game. This means that with almost every change we argue and discuss a lot before making a final decision. Sometimes we argue about everything, from the smallest GUI change, to how a major feature should work. This is probably not a bad thing since this means changes are usually well thought out and unpopular ideas or changes don't make it to the game very often. Some people feel quite strongly about their opinions or sometimes the team is very divided on what should we do. Today we'll share some of those opinions and controversies. Keep in mind that these are simply opinions and none of them will actually make it into the game, we are simply sharing them to have an interesting discussion.

Hello, we had a party last night in the office to celebrate the work we have done over the last 6 months on 0.17 stablisation. It was nice to have most of the team together to share some beers and pizza.

Hello, We had a lovely surprise waiting us this Monday, one of our fans had sent us a delicious cake: It didn't last very long... Thank you very much Conn! It certainly helped with the bug fixing push this week.

Warning this Friday facts is about the Introduction scenario, not about anything that will be in Freeplay Factorio. You may want to read previous FFFs (FFF-257, FFF-284) about the Introduction. TLDR: the Stable candidate of the Introduction scenario is now in Experimental please play it and send me your screenshots. Feedback especially on the “freeform endgame” would be greatly appreciated. We have also released a Experimental version of the Demo, be sure to send this link to your friends ASAP. SPOILER WARNING: If you have not yet played the Introduction Scenario, go play it before you read this.

Lua Mod GUI additions Rseding Mod GUIs have been an interesting part of Factorio modding since I started working at Wube. They allow scenarios and mods to add GUIs that look and feel like the base game. When someone new to Factorio modding is introduced to how they function, they almost always have the same questions: Why is mod GUI part of the game state? Why do mod GUIs need to be deterministic? How can I edit the base game GUIs? And then comes the explanation: The actual widgets are not part of the game state and are not deterministic. The part that mods have access to however is. In an environment where mods have to operate deterministically, if a mod is allowed to read some data that data must be deterministic. In that simple bit of logic; if a mod can read the checked state of a checkbox then that checked state needs to be deterministic. If the mod didn't have access to read that state it would need to store the last-known state and update it every time it got the changed event. Try to imagine that: every single mod implementing their own system for remembering last-known-state about GUIs they're using. Instead of leaving that entire mess to mod developers we decided long ago that we would manage that "last-known-state" for them. The basic data about what a given mod wanted to show on screen is recorded so mods can read and change it as they want and not need to be concerned with constantly updating it every time some changed event happens. Additionally it means that the game can use that "last known state" to restore what the player sees if they save, quit, and load the game. That still leaves the last question: "How can I edit the base game GUIs?". Using the above example it's much easier to explain that: as a mod - you can't. The base game GUIs are not implemented using this same system - they're just pure collections of widgets. None of the "last known state" is saved anywhere and it's all lost when saving, quitting, and loading. However, that leaves a divide: we need to implement each widget type through the "CustomGui" system in order for mods to be able to use them. With this latest release I finally figured out a way to do tabbed panes since they're special in how they work compared to everything else. Additionally I figured out a semi-friendly way for mods to put things directly on the screen in a way that the player can drag them around - instead of being limited to some fixed area (left, top, center, etc). Another system which I've been thinking about for quite some time is some way for mods to position GUI elements relative to base game GUIs. For example: a mod wants to add a pane which shows on the left of the character inventory GUI. Currently it's not possible - the base game GUI isn't readable by mods so they can't do anything with it. My idea is some system where a mod can say "I want to add this GUI, and I want it to be shown relative to the character GUI on the left side" and then any time the character GUI is shown it would also show the mod GUI. There are some critical parts to this new system. It needs to: Be easy to expand (either automatically works with all new base game GUIs or works with minimal effort). Not break with simple refactoring. Not cause other programmers trouble by existing. Not prevent base game GUIs from working how they need to work. So far none of it seems impossible. I don't know when I'll have it working, but I'm looking forward to what mods will do with it.

Hello, We are down to 28 bugs on the forum. The last bugs are often the ones we have been putting off for a reason, they generally require some more meaningful changes and decisions. That is why this week we have a lot to discuss.

Under 100 bugs We have a record low in our bug report forum, of only 55 active bug reports. I don't think in the history of Factorio the bug forum has been so clean. No doubt once we mark 0.17 as stable the count will shoot up again. For this weeks graph I added the count of players on Steam as the left axis. We thought it would be somewhat interesting to see if there is any correlation between the two. Note: The axis have different scales. I also prepared the same graph but for the duration of the 0.17 release. You can see our player numbers are dropping quite a lot, from the all time peak of 22,457 on the 3rd of March 2019. While bug reports might be at an all time low, we are not going to call the game stable yet. We still have an important milestone to reach, that is, implementing the new Introduction campaign graphics (FFF-301). A lot of the team has been on vacation these last few weeks, including the whole campaign team and most of the art department. What this means is that we expect it will be a few more weeks before we can call the current version stable. We have been asked a few times when stable will be released, but my question is, why does it matter exactly which version we call stable? Are you waiting for stable to play a new playthrough? The thing is, this stable is only going to be the 'first' stable. Our plan is to have a number of short experimental phases after the first stable, where we will add new GUI's and such, which will add bugs and technical debt. After fixing the bugs in a 'small' experimental content release, we will then mark that as the 'new' 0.17 stable. Besides, there are still a few edge cases with signals that kovarex is busy fixing: For instance the setup above took him 3 hours to fix. The cause of the issue was that the segment has both an incoming and outgoing signal at the same position.

The multiplayer megapacket Twinsen Last month I joined KatherineOfSky's MMO event as a player. I noticed that after we reached a certain number of players, every few minutes a bunch of them got dropped. Luckily for you (but unluckily for me), I was one of the players who got disconnected every, single. time, even though I had a decent connection. So I took the matter personally and started looking into the problem. After 3 weeks of debugging, testing and fixing, the issue is finally fixed, but the journey there was not that easy. Multiplayer issues are very hard to track down. Usually they only happen under very specific network conditions, in very specific game conditions (in this case having more than 200 players). Even when you can reproduce the issue it's impossible to properly debug, since placing a breakpoint stops the game, messes up the timers and usually times out the connection. But through some perseverance and thanks to an awesome tool called clumsy, I managed to figure out what was happening. The short version is: Because of a bug and an incomplete implementation of the latency state simulation, a client would sometimes end up in a situation where it would send a network package of about 400 entity selection input actions in one tick (what we called 'the megapacket'). The server then not only has to correctly receive those input actions but also send them to everyone else. That quickly becomes a problem when you have 200 clients. It quickly saturates the server upload, causes packet loss and causes a cascade of re-requested packets. Delayed input actions then cause more clients to send megapackets, cascading even further. The lucky clients manage to recover, the others end up being dropped. The issue was quite fundamental and took 2 weeks to fix. It's quite technical so I'll explain in juicy technical details below. But what you need to know is that since Version 0.17.54 released yesterday, multiplayer will be more stable and latency hiding will be much less glitchy (less rubber banding and teleporting) when experiencing temporary connection problems. I also changed how latency hiding is handled in combat, hopefully making it look a bit smoother.

Crash site: First state Ernestas, V453000, Albert For many weeks now the GFX department has been focused on preparing replacements for the placeholder graphics of the campaign crash site. The subject as usual is not that easy because we had to first solve the main concept of the crash site. It happens that those new entities belong to the Factorio universe, but they come from a different reality than the usual DIY/diesel punk of the game. So we had to invent a new way to design machines that look like Factorio but that are not too familiar. Here a proof of concept of the look: The concept is that the big (medium) spaceship broke into pieces as it crash landed, and lost many components that the player, during the introduction, will repair and use for his own profit. The look of the spaceship remnants are a little bit based on the designs of the 60’s/70’s pulp Sci-Fi. Fortunately we can keep the look of Factorio due the accident, which allows us to destroy and dirty up the machines show many inner mechanical details. It is also part of the concept that all the machines that the player builds, are based on an existing technology from his home planet. So the machines that we see in the regular game are like 'cheap' versions of the original ones. For the lab, we keep the dome shape and the beams inside in order to keep consistency with the regular laboratory. So slowly the player gets used to the meaning of the shapes. The generator is similar to a substation -more or less-, connectable like a pole but it also produces electricity. Sometimes we really have to invent. This works like an assembling machine. The design is more based in the (yet unshown) redesign of the assembling machines, rather than on the actual 'classic' ones. These cylinders are like chests. We decided to make them cylindrical instead of a box for this difference in technology level that we are speaking about. The player will recognize them for the shape, color, and they also always have a number printed. You don’t really want to know the meaning of the numbers. All this new content is a work in progress, and we made these new entities first for the testing of the campaign. Based on feedback with testers we will have the chance to tweak and adapt whatever is necessary. In the case of the introduction, the positioning of the entities can have a large impact on the flow of the gameplay. Once we are more sure of the final placement, we can see how all the pieces will fit together. The next round for the crash site is the main crashed spaceship, and some other assets that converts the scene into a full composition, more proper for the introduction of the game.